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Abstract — The  effectiveness  of  ground-based,  wireless  tacti¬ 
cal  data  networks  is  often  constrained  by  limitations  such  as 
communication  range  and  line-of-sight.  SATCOM  is  not  always 
available  because  it  is  relatively  expensive  and  highly  contended. 
Data  ferrying  is  an  alternative  method  of  data  transfer  in  which 
data  is  uploaded  from  one  network  to  a  manned  or  unmanned 
vehicle,  then  the  vehicle  is  driven  or  flown  to  within  range  of  a 
second  network  where  the  data  can  be  downloaded.  Data  ferrying 
via  Unmanned  Aerial  Vehicle  (UAV)  can  transport  data  over  very 
rugged  terrain  without  risking  the  safety  of  a  human  courier. 

This  paper  describes  an  implementation  of  data  ferrying  to 
provide  low-cost,  effective  data  communications  between  remote 
ground  units  and  Forward  Operating  Bases  (FOBs)  in  austere 
environments.  It  describes  a  field  experiment  in  which  a  ground 
vehicle  was  used  to  wirelessly  ferry  data  in  a  realistic  scenario, 
and  points  out  the  lessons  learned  from  that  experiment. 

I.  Introduction 

As  data  communications  become  increasingly  central  to 
tactical  operations,  the  need  to  transmit  data  reliably  over 
long  distances  and  over  rugged  terrain  becomes  increasingly 
important.  Tactical  operations  offer  additional  challenges  to 
maintaining  communications,  including  the  following: 

•  Rapidly  deployed  command  centers  such  as  Forward 
Operating  Bases  (FOBs)  without  secure,  high-capacity 
network  access. 

•  The  need  to  communicate  with  mobile  tactical  person¬ 
nel  and  patrols,  which  have  limited  communication  and 
power  resources,  move  in  and  out  of  range,  and  can  be 
highly  susceptible  to  obstructions  and  weather  that  affects 
communications . 

Current  wireless  tactical  networks  are  typically  limited  to 
line-of-sight  communication  ranges.  One  approach  to  long- 
range  data  communications  is  reachback  to  a  global  data 
network.  This  may  not  be  possible  in  austere  environ¬ 
ments,  such  as  those  in  which  FOBs  and  mobile  troops  are 
rapidly  deployed.  A  second  option,  Satellite  Communications 
(SATCOM),  is  relatively  expensive  and  its  bandwidth  is  highly 
contended,  so  it  can  be  impractical  for  transferring  the  gigabyte 
volumes  of  data  required  by  emerging  tactical  information 
systems.  A  third  method  is  to  interconnect  wireless  tactical 


Fig.  1.  Data  Ferrying  moves  information  over  long  distances  more  quickly 
and  safely  than  SATCOM  or  using  a  human  courier. 


networks  by  a  series  of  line-of-sight  links  to  form  a  bridge, 
which  can  be  difficult  to  maintain  with  mobile  troops. 

Data  Ferrying  is  an  alternative  method  for  providing  a 
high-bandwidth,  low  cost,  and  safe  way  to  transport  informa¬ 
tion  bi-directionally  to  and  from  remote  areas,  as  shown  in 
Figure  1.  An  Unmanned  Aerial  Vehicle  (UAV)  with  a  short- 
range/high-bandwidth  radio  can  bring  packages  of  mission 
planning  and  intelligence  information  (e.g.,  current  satellite 
imagery)  to  a  remote  area,  and  reciprocally  transport  archives 
of  data  (such  as  photographs  and  raw  sensor  data)  from  the 
tactical  edge  back  to  a  larger  installation  for  processing  and 
analysis.  The  general  concept  is  that  a  ground  or  air  vehicle 
(such  as  a  UAV)  is  driven  or  flown  between  two  networks, 
automatically  uploading  a  pre-designated  set  of  data  from  the 
source  network  and  then  automatically  downloading  it  to  the 
destination  when  it  comes  within  range.  Ferrying  a  gigabyte  of 
data  by  a  UAV  such  as  a  Scan  Eagle  from  a  FOB  to  a  mobile 
deployment  100  miles  away  can  be  done  in  less  than  five  hours, 
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Fig.  2.  Data  Ferrying  network  scenario. 

versus  eight  hours  by  HMMWV  (with  extra  manpower  and 
exposure  to  threats)  and  87  hours  via  satellite  communications. 

Data  ferrying  differs  from  network  bridging  in  that  it  elimi¬ 
nates  the  requirement  for  two  networks  to  be  interconnected  by 
a  chain  of  line-of- sight  bridges.  Instead,  data  is  moved  between 
networks  using  a  single  device  that  connects  to  one  network  to 
upload  data  first,  then  travels  within  range  of  the  other  network 
to  download  it. 

The  contributions  of  this  paper  include: 

•  A  description  of  the  requirements,  design,  and  implemen¬ 
tation  of  a  functional  data  ferrying  system  suitable  for 
deployment  on  a  UAV. 

•  The  results  of  a  field  experiment  that  evaluates  the  data 
ferry’s  performance  in  a  realistic,  ground-based  scenario. 

This  paper  is  organized  as  follows.  Section  I  motivates  the 
need  for  data  ferrying  in  tactical  data  networks  and  provides 
background  into  the  technologies  we  utilize  to  implement  a 
data  ferrying  capability.  Section  II  describes  our  approach 
to  design  a  data  ferrying  capability  for  providing  low-cost, 
effective  data  communications  between  remote  ground  units 
and  FOBs  in  austere  environments.  Section  III  describes  a  field 
experiment  that  we  conducted  using  a  ground  vehicle  to  wire¬ 
lessly  ferry  data  in  a  realistic  scenario.  Section  IV  discusses 
some  of  the  other  related  work  that  has  been  conducted  in 
data  ferrying.  Finally,  Section  V  provides  some  conclusions 
and  discussion  of  future  work. 

A.  Motivation 

Consider  a  situation  where  a  group  of  soldiers  are  commu¬ 
nicating  between  themselves  over  their  local  network.  At  some 
point,  the  group  leader  needs  to  share  a  piece  of  information 
with  personnel  at  the  FOB.  Unfortunately,  the  FOB  is  now 
tens  of  miles  away,  and  there  is  no  available  network  bridge. 

However,  with  a  data  ferrying  capability,  the  soldiers  and 
FOB  can  exchange  information  with  each  other,  by  storing  the 
information  in  an  airborne  ferry  and  automatically  sending  it 
to  the  FOB  when  it  comes  within  range  of  the  ferry,  as  shown 
in  Figure  2. 

B.  Background 

Our  data  ferrying  design  and  implementation  is  based 
on  two  technologies:  the  Marti  information  broker  and  the 
Android  Tactical  Assault  Kit  (ATAK)  situational  awareness 
application.  In  this  section,  we  describe  these  technologies 
and  discuss  the  network  environment  in  which  data  ferrying 
operates. 


Fig.  3.  Marti  is  a  publish-subscribe  information  broker  providing  information 
dissemination  through  QoS-managed  tactical  radio  links. 


1 )  Marti:  Marti  is  an  advanced  tactical  information  man¬ 
agement  system  that  can  be  deployed  on  a  low-cost  single¬ 
board  computer.  Marti  uses  a  publish-subscribe  model:  in¬ 
formation  producers  (publishers)  are  decoupled  from  infor¬ 
mation  consumers  (subscribers).  Publishers  submit  informa¬ 
tion  to  Marti  with  metadata  describing  the  time,  location, 
and  content  of  the  information.  Subscribers  register  a  policy 
describing  their  information  needs  (their  subscription )  and 
Marti  automatically  delivers  published  information  matching 
that  subscription.  Marti  also  supports  archiving  published 
information  and  allows  consumers  to  query  the  archive  for 
relevant  information  that  was  published  in  the  past.  Marti  can 
communicate  over  any  IP  network,  including  tactical  wireless 
IP  networks.  As  shown  in  Figure  3,  Marti  can  be  deployed 
on  a  manned  or  unmanned  aircraft  to  provide  Beyond  Line  of 
Sight  (BLOS)  data  communications.  Marti  provides  Quality  of 
Service  (QoS)  management  to  adjust  and  prioritize  message 
traffic  to  the  bandwidth  available  and  to  meet  low-bandwidth 
requirements  on  tactical  networks.  More  detail  about  the  Marti 
system  is  available  in  [1]  and  in  [2].  [3]  explains  how  Marti  is 
used  to  extend  communications  to  BLOS  in  wireless  network 
environments. 

Marti  supports  communications  in  a  variety  of  formats, 
including  Cursor  on  Target  (CoT)  [4]  and  HTTP.  CoT  is  an 
extensible  Markup  Language  (XML)-based  data  interchange 
protocol  that  is  required  by  the  Department  of  Defense  (DoD) 
to  be  used  in  many  applications.  Marti  uses  the  Apache 
Tomcat  web  application  server  to  handle  all  HTTP  interactions 
including  a  user  interface  for  tactical  users. 

2)  ATAK:  ATAK  is  a  situational  awareness  application 
designed  for  mobile  devices  running  the  Android  Operating 
System.  It  features  a  moving  map  with  support  for  displaying 
offline  map  layers  and  sharing  information  over  a  network. 

ATAK  can  share  information  in  a  variety  of  formats, 
including  CoT  and  file  transfers  over  HTTP.  Mission  Packages 
are  specially  formatted  files  that  are  shared  by  ATAK  and  the 
content  of  which  can  be  displayed  on  the  destination  device(s). 
Mission  package  availability  is  advertised  via  CoT,  transferred 
over  HTTP,  and  acknowledged  over  CoT. 


3)  Network  Assumptions:  Both  Marti  and  ATAK  are 
network-agnostic  in  that  they  only  rely  on  an  underlying 
IP  network.  Thus,  we  assume  that  the  network  is  capable 
of  supplying  IP  connectivity  and  routing.  Furthermore,  both 
applications  utilize  well-known  multicast  groups  to  discover 
network  services  (such  as  the  presence  of  other  applications 
on  the  network).  Thus,  we  also  assume  that  the  network  can 
support  (or  at  least  emulate)  standard  IP  multicast. 

For  the  data  ferrying  capability,  we  require  that  the  ferrying 
device  is  addressable  at  the  IP  layer  by  the  device(s)  that  will 
contribute  data  to  be  ferried  and  consume  the  ferried  data. 
Also,  the  data  producers  and  consumers  must  be  IP  addressable 
by  the  data  ferry.  Since  the  data  producers  and  data  consumers 
are  not  addressable  simultaneously  (by  definition  of  data 
ferrying),  the  data  ferry  must  be  able  to  join  multicast  groups 
and  send  data  via  multicast  on  each  of  the  data  producers’  and 
data  consumers’  networks.  We  make  no  assumptions  about 
the  number  of  networks  (i.e.,  there  can  be  multiple  network 
interfaces/radios)  as  long  as  the  consumers  can  be  addressed 
via  IP  by  the  data  ferry. 

II.  Approach 

Our  main  approach  to  providing  a  data  ferrying  capability 
is  to  augment  Marti  with  support  for  advertising  mission 
packages  to  be  ferried,  and  for  receiving,  storing,  and  for¬ 
warding  mission  packages  to  designated  recipients  when  they 
are  automatically  discovered.  This  includes  augmenting  Marti 
with  the  following  capabilities: 

1)  Receiving  mission  package  advertisements  and  download¬ 
ing  mission  packages; 

2)  Maintaining  a  list  of  ATAK  contacts,  their  open  network 
IP/port,  their  names,  and  the  last  time  we  received  an 
advertisement  from  them;  and 

3)  Sending  mission  package  advertisements  upon  connecting 
to  a  specified  mission  package  receiver. 

We  added  a  Data  Ferry  component  to  Marti  that  can  be 
enabled/disabled  at  runtime.  The  Data  Ferry  component  is 
configured  with  a  list  of  mission  package  receiver  names  and 
the  amount  of  time  (in  seconds)  that  an  ATAK  contact  is 
considered  disconnected. 

Basically,  the  ferrying  process  works  as  follows.  An  ATAK 
instance  on  a  device,  which  can  be  a  soldier’s  handheld  device 
or  in  a  FOB,  puts  together  a  mission  package  that  it  wants 
to  ferry  and  advertises  it.  When  a  Marti  instance  on  the 
ferry  comes  within  range,  it  receives  the  Mission  Package 
advertisement  and  uploads  the  mission  package.  When  Marti 
discovers  an  ATAK  instance  (which  could  be  on  a  soldier’s 
handheld  device  or  in  a  FOB)  that  matches  the  recipient  list 
for  the  mission  package,  Marti  downloads  the  mission  package 
to  that  ATAK  instance. 

The  data  flow  for  the  Data  Ferry  component,  illustrated  in 
Figure  4,  is  event-driven.  There  are  two  separate  events  that 
trigger  processes  in  the  Data  Ferry  component:  (1)  the  receipt 
of  an  ATAK  advertisement  meaning  that  an  ATAK  instance  is 
in  range  of  the  ferry,  and  (2)  the  receipt  of  a  Mission  Package 
advertisement,  which  means  that  a  node  has  information  to 
upload  to  the  ferry. 


Fig.  4.  Data  flow  diagram  for  Marti’s  data  ferry  component. 


Upon  receipt  of  a  Mission  Package  advertisement,  Marti 
uploads  and  persists  the  mission  package  to  disk,  which  adds  it 
to  its  current  list  of  Mission  Packages.  Simultaneously,  Marti 
sends  an  acknowledgement  that  it  successfully  uploaded  the 
Mission  Package  to  the  ATAK  instance  from  which  it  was 
uploaded. 

Marti’s  Data  Ferry  component  is  also  listening  for  ad¬ 
vertisements  from  ATAK  instances — maintaining  a  list  of 
contact  names,  last  advertisement  received  time,  and  the  IP 
address/port/protocol  upon  which  the  application  is  listening. 
When  it  receives  an  advertisement,  Marti  adds  or  updates  the 
contact’s  information  in  its  contact  list.  If  the  contact  is  listed 
as  a  mission  package  receiver  in  the  configuration,  we  check 
to  see  if  this  is  a  new  (i.e.,  it  did  not  previously  appear  in 
the  contact  list)  or  “stale”  (i.e.,  the  last  advertisement  receive 
time  exceeds  the  configured  stale  time)  contact.  If  it  is  a  new 
or  stale  contact,  then  we  send  the  contact  a  list  of  mission 
packages.  The  contact  can  then  decide  which  mission  packages 
to  download  from  Marti’s  HTTP  server. 

III.  Experimental  Setup  and  Results 

The  purpose  of  the  Data  Ferrying  exercise  is  to  evaluate 
our  ability  to  move,  with  a  single  transport,  many  types  of 
information  between  disconnected  groups  of  users  that  are 
separated  by  distances  that  far  exceed  current  network  bridging 
capabilities. 

A.  Experimental  Setup 

The  experiment  was  conducted  as  part  of  an  integration 
activity  meant  to  test  many  different  technologies.  As  such,  it 
occurred  over  the  course  of  one  day  with  extremely  limited 


Fig.  5.  Raspberry  Pi,  battery,  radio,  and  case  for  the  data  ferry. 

range-time,  thus  limiting  the  number  of  experiments  and 
repetitions  that  we  could  perform. 

1 )  Hardware:  The  data  ferry  ran  on  a  Raspberry  Pi  (Rev 
B)  single-board  computer  with  a  15000mAh  external  battery 
and  connected  to  Persistent  System’s  Wave  Relay  MPU4 
tactical  radio.  The  external  battery  is  capable  of  powering  the 
Raspberry  Pi  for  approximately  21  hours  and  the  MPU4  is 
capable  of  running  for  14  hours.  The  components  were  placed 
in  a  cloth  case  as  shown  in  Figure  5  and  transported  by  a 
Polaris  RZR  XP  four-wheel  ground  vehicle. 

The  ATAK  system  consists  of  Samsung  Galaxy  Nexus 
and  first-generation  Nexus  7  Android  devices  connected  to  an 
802.11  WiFi  network  with  a  bridge  to  the  tactical  Wave  Relay 
network  through  Persistent  System’s  Quad  Radio  Router. 

2 )  Experiment  Scenario:  An  ATAK  user  (designated  as 
Remote  ATAK)  is  sent  to  a  remote  location  out  of  network 
range  of  the  FOB.  This  device  represents  a  deployed  asset  in 
an  austere  location.  An  ATAK  user  at  the  FOB  (designated 
as  FOB  ATAK)  utilizes  ATAK  to  produce  a  mission  package. 
Mission  packages  can  contain  various  data  types  including,  but 
not  limited,  to  the  following: 

•  A  photograph  (e.g.,  JPG), 

•  An  ATAK  Map  package, 

•  A  geo-referenced  map  file  (e.g.,  GeoTiff), 

•  Elevation  data  (e.g.,  DTED), 

•  A  gridded  reference  graphic  (GRG), 

•  A  configuration  file  (e.g.,  XML), 

•  A  security  certificate  (e.g.,  PKCS  12), 

•  A  video  (e.g.,  mp4), 


•  A  geo-referenced  annotation  file  (e.g.,  KML), 

•  A  geo-spatial  route, 

•  An  audio  clip,  (e.g.,  mp3),  and 

•  CoT  (spatio-temporal)  data. 

The  FOB  ATAK  user  waits  until  ATAK  discovers  the 
periodic  heartbeat  messages  from  Marti  on  the  airborne  data 
ferry.  Then,  the  FOB  ATAK  user  sends  the  Mission  Package  to 
the  Data  Ferry.  When  the  Data  Ferry  has  successfully  received 
the  file,  the  FOB  ATAK  displays  a  notification. 

Marti  is  configured  with  a  list  of  users  such  that,  when 
each  user  becomes  reachable  by  radio,  Marti  informs  that  user 
about  Data  Ferry  file(s)  that  it  can  download. 

During  the  experiment,  the  FOB  ATAK  user  tasks  the  data 
ferry  transport  to  move  to  the  area  where  the  Remote  ATAK 
user  was  sent.  When  the  Data  Ferry  nears  the  Remote  ATAK, 
Marti  sees  the  Remote  ATAK’s  position  updates  and  sends 
the  Remote  ATAK  the  file(s)  that  were  uploaded  by  the  FOB 
ATAK.  ATAK  automatically  downloads  the  files  that  Marti 
advertises  and  displays  a  notification  to  the  Remote  ATAK 
user  when  the  download  is  successfully  completed. 

3)  Data  Collection:  During  the  experiment,  we  collected 
a  significant  amount  of  data  that  enabled  us  to  evaluate  the 
efficacy  and  performance  of  the  data  ferrying  capability.  We 
were  particularly  interested  in  measures  of  latency,  because 
latency  is  typically  a  primary  concern  for  users  awaiting 
data  in  the  field.  Additionally,  measurements  of  application- 
level  latency  intrinsically  incorporate  the  time  requirements  for 
lower-layer  (e.g.,  network)  failures  and  recovery  mechanisms 
for  handling  those  failures  (e.g.,  timeouts,  retries,  back-offs). 

To  acquire  latency  measurements,  Marti ’s  data  ferry  service 
was  instrumented  at  the  completion  of  each  stage  with  time- 
stamped  log  messages.  All  the  logging  was  collected  on  the 
data  ferry  to  eliminate  the  need  for  time  synchronization 
between  devices.  The  times  that  were  logged  include: 

•  Times  at  which  ATAK  users  are  discovered 

•  Time  when  mission  package  uploads  begin 

•  Time  when  mission  package  uploads  end 

•  Times  at  which  ATAK  users  are  notified  of  new  files  to 
download 

•  Time  when  a  file  download  begins  for  each  user 

•  Time  when  a  file  download  ends  for  each  user 

B.  Experimental  Results 

Table  I  shows  the  quantitative  experimental  results  for  two 
experiments.  Both  experiments  used  the  same  hardware  and 
software,  and  transferred  the  same  14MB  (compressed)  mis¬ 
sion  package,  but  the  experiments  differed  in  the  networking 
situation.  For  both  experiments,  the  FOB  was  situated  between 
two  lakes  and  surrounded  by  a  densely  wooded  area  as  shown 
in  Figure  6. 

In  the  Stationary  Ferry  Experiment ,  the  data  ferry  was 
placed  within  range  of  both  the  FOB  ATAK  and  Remote  ATAK 
and  remained  there  stationary  for  the  duration  of  the  experi¬ 
ment.  The  Remote  ATAK  was  turned  off  (i.e.,  not  running 
ATAK)  until  the  remote  user  wanted  the  mission  package. 

In  the  Mobile  Ferry  Experiment ,  the  data  ferry  was  loaded 
with  mission  packages  from  the  FOB  ATAK  and  driven  via  a 


Fig.  6.  Area  covered  by  the  mobile  data  ferry  experiment. 


TABLE  I.  Experimental  Results 


Category 

Stationary  Ferry 
Experiment 

Mobile  Ferry 
Experiment 

Upload  Start  — >  Complete 

<  2s 

78s 

Number  of  upload  failures 

0 

1 

Notification  — >  Download  Start 

<  Is 

88s 

Number  of  notification  failures 

0 

2 

Download  Start  — »■  Complete 

<  2s 

103s 

Number  of  download  failures 

0 

6 

ground  vehicle  to  an  austere  location.  The  Remote  ATAK  was 
turned  off  (i.e.,  not  running  ATAK)  until  the  data  ferry  was 
out  of  range  (at  a  distance  of  approximately  775m)  as  shown 
in  Figure  6.  After  starting  the  Remote  ATAK,  the  data  ferry 
was  driven  back  towards  the  FOB  and  left  within  range  of  the 
FOB  for  several  minutes. 

The  “failures”  that  are  counted  in  Table  I  are  all 
application-level  networking  failures — i.e.,  errors  that  are  prop¬ 
agated  to  the  application-layer  rather  than  errors  that  are 
handled  transparently  (e.g.,  TCP  re-transmits). 

C.  Analysis 

The  results  from  Table  I  show  that  each  stage  of  the 
data  ferrying  component  of  Marti  completed  in  under  two 
seconds  when  networking  conditions  were  near  ideal  (as  in 
the  stationary  ferry  experiment).  With  no  application- visible 
networking  failures,  the  mission  package  was  automatically 
transferred  from  Marti  to  ATAK  in  less  than  three  seconds 
after  ATAK  was  discovered. 

However,  the  effect  of  mobilizing  the  data  ferry  on  the 
network  was  substantial.  Operating  at  the  borders  of  the 
network’s  range  caused  a  considerable  number  of  application- 
level  networking  failures.  These  failures,  as  well  as  lower-level 
errors  (e.g.,  TCP  re-transmits)  caused  the  relative  latencies  to 
be  significantly  higher  in  the  mobile  ferry  experiment  than 
the  stationary  ferry  experiment.  The  network  conditions  that 
caused  these  failures  are  difficult  to  reproduce  in  simulation 
or  laboratory  testing  due  to  the  complexities  in  emulating  the 
physical  and  data-link  layers  of  the  situation.  Thick  foliage  and 


RF  interference  could  have  played  important  roles  in  causing 
the  networking  errors  in  the  mobile  ferry  experiment. 

A  qualitative  result  from  this  experiment  was  the  re¬ 
enforced  need  for  robust  network  error  handling.  During  any  of 
the  phases  of  the  upload/download  process,  application-layer 
network  errors  can  occur  over  lossy  data  links.  In  the  case 
of  our  mobile  ferry  experiment,  errors  occurred  in  each  step 
of  the  process,  i.e.,  during  upload,  notification,  and  download. 
Different  forms  of  error  handling  were  created  for  each  stage, 
however.  For  example,  the  upload  and  download  failures  were 
limited  to  ten  attempts  (each)  separated  by  a  short,  but  constant 
waiting  period  before  they  would  quit  and  report  an  error  to 
the  user  through  ATAK.  The  notification  failures  were  handled 
differently  in  that  they  would  retry  indefinitely,  but  backoff 
exponentially  between  retries  (up  to  a  maximum  interval  of 
one  minute).  To  ensure  that  the  data  ferry  successfully  transfers 
its  mission  packages  in  all  situations,  robust  forms  of  error 
handling  are  critical. 

IV.  Related  Work 

Prior  work  in  data  ferrying  has  been  dominated  by  research 
in  the  routing  and  control  of  ferries.  This  is  different  from  our 
emphasis  in  this  paper;  we  assume  that  the  ferry  is  under  the 
control  of  an  operator  or  flying  routes  determined  by  other 
missions  it  is  supporting.  However,  the  work  is  directly  related 
to  the  results  that  we  report  in  this  paper.  The  Switch-and- 
Navigate  (SAN)  approach  is  a  hierarchical  approach  that  uses  a 
global  policy  (Switch)  that  moves  a  ferry  between  disconnected 
networks  and  a  local  (Navigate)  policy  that  searches  for  nodes 
within  a  network  for  upload  or  download  of  information  [5]- 
[8].  The  SAN  algorithms  for  searching  for  a  node  within  a 
network  would  be  a  useful  extension  to  our  data  ferrying 
implementation  in  cases  where  the  ferry  cannot  sense  the  full 
range  of  nodes  within  a  network,  e.g.,  if  some  nodes  are 
beyond  the  range  of  the  ferry’s  radios. 

Another  approach  to  routing  of  ferries  treats  the  ferries 
as  intelligent  agents  and  applies  Markov  Decision  Processes 
(MDP)  to  learn  an  optimal  route  for  the  ferry  [9].  A  variation 
on  this  approach  chains  multiple  ferries  together  to  move 
information  long  distances  [10].  Both  of  these  are  overkill  for 
the  purposes  of  the  experiments  that  we  are  conducting  and  the 
users  that  we  are  targeting,  although  they  are  opportunities  for 
extending  the  capabilities  that  we  have  prototyped.  Medium 
size  UAVs,  like  the  Scan  Eagle,  have  significant  range  and 
duration  —  1500  km  and  28  hours  for  the  Scan  Eagle  — 
meaning  that  each  can  ferry  for  a  large  area  and  time  period. 
Smaller  UAVs,  like  the  Puma,  which  have  lower  range  and 
duration  (3.5  hours)  would  be  in  more  need  of  chaining  and 
intelligent  routing  capabilities.  In  these  situations,  deploying 
multiple  ferries  at  a  time  could  require  algorithms  for  routing 
and  controlling  multiple,  cooperating  ferries,  such  as  those 
provided  by  Zhao  et  al  [11]. 

Related  to  the  movement  of  ferries  is  managing  the  transfer 
of  information  from  a  node  on  the  ground  to  the  ferry  (upload) 
and  from  the  ferry  to  a  node  on  the  ground  (download).  The 
ferry  must  stay  within  line  of  sight  of  the  node  for  the  duration 
of  the  transfer.  Pearre  describes  an  algorithm  to  compute  a  path 
through  airspace  within  line  of  sight  of  a  node  that  wishes  to 
upload  information  to  the  UAV,  where  the  path  is  the  shortest 
possible,  but  enables  transfer  of  the  full  set  of  data  [12]. 


An  issue  that  we  don’t  address  in  this  paper,  but  could  be 
important  to  particular  deployments  of  data  ferries  is  power 
management.  Jun  et  al  describe  an  approach  to  computing 
the  time  until  a  ferry  is  in  range,  so  that  a  node  can  sleep 
when  a  ferry  is  away,  and  wake  up  when  the  ferry  is  in 
range,  conserving  power  [13].  Yang  et  al  provide  algorithms 
for  handling  failures  in  ferries,  i.e.,  by  using  multiple  ferries 
to  provide  fault  tolerance  for  one  another  [14]. 

V.  Conclusions 

Data  ferrying  is  a  powerful  method  for  connecting  discon¬ 
nected  networks  and  is  especially  useful  for  tactical  military 
operations  to  link  soldiers  with  command  centers  or  to  bridge 
participants  in  remote  operations  in  which  communication 
infrastructure  is  not  available,  inaccessible,  or  unreliable.  We 
have  built  a  data  ferrying  capability,  building  upon  two  existing 
technology  bases  that  are  successfully  used  in  current  military 
scenarios.  The  Marti  pub- sub  information  broker  provides 
rapidly  deployed  tactical  communications,  while  ATAK  (one 
of  the  large  sets  of  client  applications  that  Marti  supports) 
provides  a  rich  set  of  situational  awareness  functions  in  a 
small  Android  platform.  We  created  the  data  ferrying  capa¬ 
bility  by  developing  new  functions  for  Marti  and  ATAK  for 
creating  mission  packages;  advertising  them;  and  uploading, 
storing,  and  downloading  them;  along  with  new  capabilities  to 
auto-discover  ATAK  instances,  identify  them  as  recipients  of 
mission  packages,  offer  a  list  of  mission  packages  to  ATAK 
users,  and  enable  selection  for  downloading. 

This  new  data  ferrying  capability  is  integrated  as  part  of 
the  existing  Marti  and  ATAK  software,  which  means  that  it  is 
available  for  use  by  the  growing  set  of  current  users  and  eval¬ 
uators  of  Marti  and  ATAK,  which  includes  military  personnel. 
The  experiments  that  we  have  conducted  and  described  in  this 
paper  provide  us  with  data  and  metrics  that  we  plan  to  use  to 
optimize  and  improve  the  baseline  data  ferrying  capabilities. 

The  baseline  data  ferrying  capability  that  we  have  designed 
and  implemented  has  built  upon  the  prior  work  conducted  by 
others,  although  we  have  not  (yet)  emphasized  areas  in  which 
much  prior  research  has  concentrated,  such  as  ferry  routing, 
control,  and  fault  tolerance.  On  the  other  hand,  we  have 
addressed  important  issues  that  have  been  under-represented 
in  the  current  literature,  including  QoS  management,  upload 
and  download  management,  and  client  user  interfaces.  In 
the  future,  we  expect  to  introduce  and  address  additional 
functionality,  such  as  information  lifecycle  management  (e.g., 
how  long  to  retain  mission  packages),  fault  tolerance,  and 
power  management.  Also,  we  hope  to  repeat  these  experiments 
with  an  airborne  data  ferry  transport. 
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Acronym  List 

FOB  Forward  Operating  Base 


UAV  Unmanned  Aerial  Vehicle 

ATAK  Android  Tactical  Assault  Kit 

CoT  Cursor  on  Target 

BLOS  Beyond  Line  of  Sight 

XML  extensible  Markup  Language 

DoD  Department  of  Defense 

QoS  Quality  of  Service 

SATCOM  Satellite  Communications 
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